The Internet's core bandwidth continues to increase every year. Some of this additional bandwidth is consumed as more and more users access the Internet. Other additional bandwidth is consumed as existing users increase their use of the Internet. This increase of Internet use translates into an increase in traffic directed to and from World Wide Web (WWW) servers and other servers connected to the Internet.
In a typical Web session between a client and a server, each time the user clicks the mouse to visit a Web site, several processes are initiated. The server opens a socket, allocates memory for the user, acknowledges the user's Hypertext Transport Protocol (HTTP) request, fetches the data from disk memory, returns the data, and closes the session. The entire process is initiated again with the next mouse click.
A typical Web page includes multiple objects. In the past, for each object requested, a separate TCP connection (a bi-directional byte stream or roadway) was created and torn down. This caused both overhead and latency in responding to requests. It caused overhead, in part, because for each object requested, a server would have to create, maintain, and tear down a connection. It caused latency, in part, because creating and tearing down connections require multiple packets to be sent between devices that may be around the globe from each other.
HTTP version 1.1 includes a feature called session keep-alives, or just keep-alives. The HTTP version 1.1 keep-alive protocol partially addresses latency, bandwidth, and server/network problems by consolidating and maintaining a single TCP connection for HTTP traffic between the user and the Web system—regardless of the number and type of requests being made. In essence, a client computer opens an HTTP connection to a server and sends requests along this connection. The server sends responses in the opposite direction. HTTP version 1.1 may work adequately when only one client and one server are involved. When many clients are involved, however, responding to requests in a timely manner often requires more resources than a server has.
Replacing a server with a server of twice the capacity is a costly undertaking. Adding additional servers to form a group of servers servicing requests is less costly but generally requires a traffic management device (hereinafter “traffic manager”) to distribute traffic. The traffic manager may be configured to distribute traffic to each server so that multiple servers can service requests. Distributing traffic to more than one server, however, has its own problems as will be illustrated below.
In addition, with a sufficient amount of traffic between client computers and servers managed by a traffic manager, the traffic manager may run out of resources to map client requests to servers.